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Default Address Selection for Internet Protocol Version 6 (IPv6) 
Abstract 


This document describes two algorithms, one for source address 
selection and one for destination address selection. The algorithms 
specify default behavior for all Internet Protocol version 6 (IPv6) 
implementations. They do not override choices made by applications 
or upper-layer protocols, nor do they preclude the development of 
more advanced mechanisms for address selection. The two algorithms 
share a common context, including an optional mechanism for allowing 
administrators to provide policy that can override the default 
behavior. In dual-stack implementations, the destination address 
selection algorithm can consider both IPv4 and IPv6 addresses -- 
depending on the available source addresses, the algorithm might 
prefer IPv6 addresses over IPv4 addresses, or vice versa. 


Default address selection as defined in this specification applies to 
all IPv6 nodes, including both hosts and routers. This document 
obsoletes RFC 3484. 

Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6724. 
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This document is subject to BCP 78 and the IETF Trust’s Legal 
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Les 


Introduction 


The IPv6 addressing architecture [RFC4291] allows multiple unicast 
addresses to be assigned to interfaces. These addresses might have 
different reachability scopes (link-local, site-local, or global). 
These addresses might also be "preferred" or "deprecated" [RFC4862]. 
Privacy considerations have introduced the concepts of "public 


addresses" and "temporary addresses" [RFC4941]. The mobility 
architecture introduces "home addresses" and "care-of addresses" 
[RFC6275]. In addition, multi-homing situations will result in more 


addresses per node. For example, a node might have multiple 
interfaces, some of them tunnels or virtual interfaces, or a site 
might have multiple ISP attachments with a global prefix per ISP. 


The end result is that IPv6 implementations will very often be faced 
with multiple possible source and destination addresses when 
initiating communication. It is desirable to have default 
algorithms, common across all implementations, for selecting source 
and destination addresses so that developers and administrators can 
reason about and predict the behavior of their systems. 


Furthermore, dual- or hybrid-stack implementations, which support 
both IPv6 and IPv4, will very often need to choose between IPv6 and 
IPv4 when initiating communication, for example, when DNS name 
resolution yields both IPv6 and IPv4 addresses and the network 
protocol stack has available both IPv6 and IPv4 source addresses. In 
such cases, a simple policy to always prefer IPv6 or always prefer 
IPv4 can produce poor behavior. As one example, suppose a DNS name 
resolves to a global IPv6 address and a global IPv4 address. If the 
node has assigned a global IPv6 address and a 169.254/16 auto- 
configured IPv4 address [RFC3927], then IPv6 is the best choice for 
communication. But if the node has assigned only a link-local IPv6 
address and a global IPv4 address, then IPv4 is the best choice for 
communication. The destination address selection algorithm solves 
this with a unified procedure for choosing among both IPv6 and IPv4 
addresses. 


The algorithms in this document are specified as a set of rules that 
define a partial ordering on the set of addresses that are available 
for use. In the case of source address selection, a node typically 
has multiple addresses assigned to its interfaces, and the source 
address ordering rules in Section 5 define which address is the 
"best" one to use. In the case of destination address selection, the 
DNS might return a set of addresses for a given name, and an 
application needs to decide which one to use first and in what order 
to try others if the first one is not reachable. The destination 
address ordering rules in Section 6, when applied to the set of 
addresses returned by the DNS, provide such a recommended ordering. 
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This document specifies source address selection and destination 
address selection separately but uses a common context so that 
together the two algorithms yield useful results. The algorithms 
attempt to choose source and destination addresses of appropriate 
scope and configuration status ("preferred" or "deprecated" in the 
RFC 4862 sense). Furthermore, this document suggests a preferred 
method, longest matching prefix, for choosing among otherwise 
equivalent addresses in the absence of better information. 


This document also specifies policy hooks to allow administrative 
override of the default behavior. For example, using these hooks, an 
administrator can specify a preferred source prefix for use with a 
destination prefix or prefer destination addresses with one prefix 
over addresses with another prefix. These hooks give an 
administrator flexibility in dealing with some multi-homing and 
transition scenarios, but they are certainly not a panacea. 


The selection rules specified in this document MUST NOT be construed 
to override an application or upper layer’s explicit choice of a 
legal destination or source address. 


1.1. Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in BCP 14, RFC 2119 
[RFC2119]. 


2. Context in Which the Algorithms Operate 


Our context for address selection derives from the most common 
implementation architecture, which separates the choice of 
destination address from the choice of source address. Consequently, 
we have two separate algorithms for these tasks. The algorithms are 
designed to work well together, and they share a mechanism for 
administrative policy override. 


In this implementation architecture, applications use APIs such as 
getaddrinfo() [RFC3493] that return a list of addresses to the 
application. This list might contain both IPv6 and IPv4 addresses 
(sometimes represented as IPv4-mapped addresses). The application 
then passes a destination address to the network stack with connect () 
or sendto(). The application would then typically try the first 
address in the list, looping over the list of addresses until it 
finds a working address. In any case, the network layer is never in 
a Situation where it needs to choose a destination address from 
several alternatives. The application might also specify a source 
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address with bind(), but often the source address is left 
unspecified. Therefore, the network layer does often choose a source 
address from several alternatives. 


As a consequence, we intend that implementations of APIs such as 
getaddrinfo() will use the destination address selection algorithm 
specified here to sort the list of IPv6é and IPv4 addresses that they 
return. Separately, the IPv6 network layer will use the source 
address selection algorithm when an application or upper layer has 
not specified a source address. Application of this specification to 
source address selection in an IPv4 network layer might be possible, 
but this is not explored further here. 


Well-behaved applications SHOULD NOT simply use the first address 
returned from an API such as getaddrinfo() and then give up if it 
fails. For many applications, it is appropriate to iterate through 
the list of addresses returned from getaddrinfo() until a working 
address is found. For other applications, it might be appropriate to 
try multiple addresses in parallel (e.g., with some small delay in 
between) and use the first one to succeed. 


Although source and destination address selection is most typically 
done when initiating communication, a responder also must deal with 
address selection. In many cases, this is trivially dealt with by an 
application using the source address of a received packet as the 
response destination and the destination address of the received 
packet as the response source. Other cases, however, are handled 
like an initiator, such as when the request is multicast and hence 
source address selection must still occur when generating a response 
or when the request includes a list of the initiator’s addresses from 
which to choose a destination. Finally, a third application scenario 
is that of a listening application choosing on what local addresses 
to listen. This third scenario is out of the scope of this document. 


The algorithms use several criteria in making their decisions. The 
combined effect is to prefer destination/source address pairs for 
which the two addresses are of equal scope or type, prefer smaller 
scopes over larger scopes for the destination address, prefer non- 
deprecated source addresses, avoid the use of transitional addresses 
when native addresses are available, and all else being equal, prefer 
address pairs having the longest possible common prefix. For source 
address selection, temporary addresses [RFC4941] are preferred over 
public addresses. In mobile situations [RFC6275], home addresses are 
preferred over care-of addresses. If an address is simultaneously a 
home address and a care-of address (indicating the mobile node is "at 
home" for that address), then the home/care-of address is preferred 
over addresses that are solely a home address or solely a care-of 
address. 
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This specification optionally allows for the possibility of 
administrative configuration of policy (e.g., via manual 
configuration or a DHCP option such as that proposed in 
[ADDR-SEL-OPT]) that can override the default behavior of the 
algorithms. The policy override consists of the following set of 
state, which SHOULD be configurable: 


o Policy Table (Section 2.1): a table that specifies precedence 
values and preferred source prefixes for destination prefixes. 


o Automatic Row Additions flag (Section 2.1): a flag that specifies 
whether the implementation is permitted to automatically add site- 
specific rows for certain types of addresses. 


o Privacy Preference flag (Section 5): a flag that specifies whether 
temporary source addresses or stable source addresses are 
preferred by default when both types exist. 


2.1. Policy Table 


The policy table is a longest-matching-prefix lookup table, much like 
a routing table. Given an address A, a lookup in the policy table 
produces two values: a precedence value denoted Precedence(A) anda 
classification or label denoted Label (A). 


The precedence value Precedence(A) is used for sorting destination 
addresses. If Precedence (A) > Precedence(B), we say that address A 
has higher precedence than address B, meaning that our algorithm will 
prefer to sort destination address A before destination address B. 


The label value Label(A) allows for policies that prefer a particular 
source address prefix for use with a destination address prefix. The 
algorithms prefer to use a source address S with a destination 
address D if Label(S) = Label(D). 


IPv6 implementations SHOULD support configurable address selection 
via a mechanism at least as powerful as the policy tables defined 
here. It is important that implementations provide a way to change 
the default policies as more experience is gained. Sections 10.3 
through 10.7 provide examples of the kind of changes that might be 
needed. 


If an implementation is not configurable or has not been configured, 


then it SHOULD operate according to the algorithms specified here in 
conjunction with the following default policy table: 
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Prefix Precedence Label 
::1/128 50 0 
22./10 40 al 
::ffff£:0:0/96 35 4 
2002::/16 30 2 
2001::/32 5 5 
£CO0s3./ 7 3 13 
22/96 1 3 
fec0::/10 1 11 
3ffe::/16 1 12 


An implementation MAY automatically add additional site-specific rows 
to the default table based on its configured addresses, such as for 
Unique Local Addresses (ULAs) [RFC4193] and 6to4 [RFC3056] addresses, 
for instance (see Sections 10.6 and 10.7 for examples). Any such 
rows automatically added by the implementation as a result of address 
acquisition MUST NOT override a row for the same prefix configured 
via other means. That is, rows can be added but never updated 
automatically. An implementation SHOULD provide a means (the 
Automatic Row Additions flag) for an administrator to disable 
automatic row additions. 


As will become apparent later, one effect of the default policy table 
is to prefer using native source addresses with native destination 
addresses, 6to4 source addresses with 6to4 destination addresses, 
etc. Another effect of the default policy table is to prefer 
communication using IPv6é addresses to communication using IPv4 
addresses, if matching source addresses are available. 


Policy table entries for address prefixes that are not of global 
scope MAY be qualified with an optional zone index. If so, a prefix 
table entry only matches against an address during a lookup if the 
zone index also matches the address’s zone index. 


2.2. Common Prefix Length 


We define the common prefix length CommonPrefixLen(S, D) of a source 
address S and a destination address D as the length of the longest 
prefix (looking at the most significant, or leftmost, bits) that the 
two addresses have in common, up to the length of S’s prefix (i.e., 
the portion of the address not including the interface ID). For 
example, CommonPrefixLen(fe80::1, fe80::2) is 64. 


3. Address Properties 
In the rules given in later sections, addresses of different types 


(e.g., IPv4, IPv6, multicast, and unicast) are compared against each 
other. Some of these address types have properties that aren’t 
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directly comparable to each other. For example, IPv6 unicast 
addresses can be "preferred" or "deprecated" [RFC4862], while IPv4 
addresses have no such notion. To compare such addresses using the 
ordering rules (e.g., to use "preferred" addresses in preference to 
"deprecated" addresses), the following mappings are defined. 


3.1. Scope Comparisons 


Multicast destination addresses have a 4-bit scope field that 
controls the propagation of the multicast packet. The IPv6 
addressing architecture defines scope field values for interface- 
local (0x1), link-local (0x2), admin-local (0x4), site-local (0x5), 
organization-local (0x8), and global (0xE) scopes (Section 2.7 of 
[RFC4291]). 


Use of the source address selection algorithm in the presence of 
multicast destination addresses requires the comparison of a unicast 
address scope with a multicast address scope. We map unicast link- 
local to multicast link-local, unicast site-local to multicast site- 
local, and unicast global scope to multicast global scope. For 
example, unicast site-local is equal to multicast site-local, which 
is smaller than multicast organization-local, which is smaller than 
unicast global, which is equal to multicast global. (Note that IPv6 
site-local unicast addresses are deprecated [RFC4291]. However, some 
existing implementations and deployments may still use these 
addresses; they are therefore included in the procedures in this 
specification. Also, note that ULAs are considered as global, not 
site-local, scope but are handled via the prefix policy table as 
discussed in Section 10.6.) 


We write Scope(A) to mean the scope of address A. For example, if A 
is a link-local unicast address and B is a site-local multicast 
address, then Scope(A) < Scope(B). 


This mapping implicitly conflates unicast site boundaries and 
multicast site boundaries [RFC4007]. 


3.2. IPv4 Addresses and IPv4—-Mapped Addresses 


The destination address selection algorithm operates on both IPv6 and 
IPv4 addresses. For this purpose, IPv4 addresses MUST be represented 
as IPv4-mapped addresses [RFC4291]. For example, to look up the 
precedence or other attributes of an IPv4 address in the policy 
table, look up the corresponding IPv4-mapped IPv6 address. 


IPv4 addresses are assigned scopes as follows. IPv4 auto- 


configuration addresses [RFC3927], which have the prefix 169.254/16, 
are assigned link-local scope. IPv4 loopback addresses (Section 
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4.2.2.11 of [RFC1812]), which have the prefix 127/8, are assigned 
link-local scope (analogously to the treatment of the IPv6 loopback 
address (Section 4 of [RFC4007])). Other IPv4 addresses (including 
IPv4 private addresses [RFC1918] and Shared Address Space addresses 
[RFC6598]) are assigned global scope. 


IPv4 addresses MUST be treated as having "preferred" (in the RFC 4862 
sense) configuration status. 


3.3. Other IPv6 Addresses with Embedded IPv4 Addresses 


TIPv4-compatible addresses [RFC4291], IPv4-mapped [RFC4291], IPv4- 
converted [RFC6145], IPv4-translatable [RFC6145], and 6to4 addresses 
[RFC3056] contain an embedded IPv4 address. For the purposes of this 
document, these addresses MUST be treated as having global scope. 


IPv4-compatible, IPv4-mapped, and IPv4-converted addresses MUST be 
treated as having "preferred" (in the RFC 4862 sense) configuration 
status. 


3.4. IPv6 Loopback Address and Other Format Prefixes 


The loopback address MUST be treated as having link-local scope 
(Section 4 of [RFC4007]) and "preferred" (in the RFC 4862 sense) 
configuration status. 


NSAP addresses and other addresses with as-yet-undefined format 
prefixes MUST be treated as having global scope and "preferred" (in 
the RFC 4862) configuration status. Later standards might supersede 
this treatment. 


3.5. Mobility Addresses 


Some nodes might support mobility using the concepts of home address 
and care-of address (for example, see [RFC6275]). Conceptually, a 
home address is an IP address assigned to a mobile node and used as 
the permanent address of the mobile node. A care-of address is an IP 
address associated with a mobile node while visiting a foreign link. 
When a mobile node is on its home link, it might have an address that 
is simultaneously a home address and a care-of address. 


For the purposes of this document, it is sufficient to know whether 
one’s own addresses are designated as home addresses or care-of 
addresses. Whether an address ought to be designated a home address 
or care-of address is outside the scope of this document. 
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4. 


Candidate Source Addresses 


The source address selection algorithm uses the concept of a 
"candidate set" of potential source addresses for a given destination 
address. The candidate set is the set of all addresses that could be 
used as a source address; the source address selection algorithm will 
pick an address out of that set. We write CandidateSource(A) to 
denote the candidate set for the address A. 


It is RECOMMENDED that the candidate source addresses be the set of 
unicast addresses assigned to the interface that will be used to send 
to the destination (the "outgoing" interface). On routers, the 
candidate set MAY include unicast addresses assigned to any interface 
that forwards packets, subject to the restrictions described below. 
Implementations that wish to support the use of global source 
addresses assigned to a loopback interface MUST behave as if the 
loopback interface originates and forwards the packet. 


Discussion: The Neighbor Discovery Redirect mechanism [RFC4861] 
requires that routers verify that the source address of a packet 
identifies a neighbor before generating a Redirect, so it is 
advantageous for hosts to choose source addresses assigned to the 
outgoing interface. 


In some cases, the destination address might be qualified with a zone 
index or other information that will constrain the candidate set. 


For all multicast and link-local destination addresses, the set of 
candidate source addresses MUST only include addresses assigned to 
interfaces belonging to the same link as the outgoing interface. 


Discussion: The restriction for multicast destination addresses is 
necessary because currently deployed multicast forwarding 
algorithms use Reverse Path Forwarding (RPF) checks. 


For site-local unicast destination addresses, the set of candidate 
source addresses MUST only include addresses assigned to interfaces 
belonging to the same site as the outgoing interface. 


In any case, multicast addresses and the unspecified address MUST NOT 
be included in a candidate set. 


On IPv6-only nodes that support Stateless IP/ICMP Translation (SIIT) 
[RFC6145], if the destination address is an IPv4-converted address, 
then the candidate set MUST contain only IPv4-translatable addresses. 
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If an application or upper layer specifies a source address, it may 
affect the choice of outgoing interface. Regardless, if the 
application or upper layer specifies a source address that is not in 
the candidate set for the destination, then the network layer MUST 
treat this as an error. If the application or upper layer specifies 
a source address that is in the candidate set for the destination, 
then the network layer MUST respect that choice. If the application 
or upper layer does not specify a source address, then the network 
layer uses the source address selection algorithm specified in the 
next section. 


5a Source Address Selection 


The source address selection algorithm produces as output a single 


source address for use with a given destination address. This 
algorithm only applies to IPv6 destination addresses, not IPv4 
addresses. 


The algorithm is specified here in terms of a list of pair-wise 
comparison rules that (for a given destination address D) imposes a 
"greater than" ordering on the addresses in the candidate set 
CandidateSource(D). The address at the front of the list after the 
algorithm completes is the one the algorithm selects. 


Note that conceptually, a sort of the candidate set is being 
performed, where a set of rules define the ordering among addresses. 
But because the output of the algorithm is a single source address, 
an implementation need not actually sort the set; it need only 
identify the "maximum" value that ends up at the front of the sorted 
list. 


The ordering of the addresses in the candidate set is defined by a 
list of eight pair-wise comparison rules, with each rule placing a 
"greater than", "less than", or "equal to" ordering on two source 
addresses with respect to each other (and that rule). In the case 
that a given rule produces a tie, i.e., provides an "equal to" result 
for the two addresses, the remaining rules MUST be applied (in order) 
to just those addresses that are tied to break the tie. Note that if 
a rule produces a single clear "winner" (or set of "winners" in the 
case of ties), those addresses not in the winning set can be 
discarded from further consideration, with subsequent rules applied 
only to the remaining addresses. If the eight rules fail to choose a 
single address, the tiebreaker is implementation-specific. 
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When comparing two addresses SA and SB from the candidate set, we say 
"prefer SA" to mean that SA is "greater than" SB, and similarly, we 
say "prefer SB" to mean that SA is "less than" SB. If neither is 
stated to be preferred, this means that SA is "equal to" SB, and the 
remaining rules apply as noted above. 


Rule 1: Prefer same address. 
If SA = D, then prefer SA. Similarly, if SB = D, then prefer SB. 


Rule 2: Prefer appropriate scope. 

If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB and 
otherwise prefer SA. Similarly, if Scope(SB) < Scope(SA): If 

Scope (SB) < Scope(D), then prefer SA and otherwise prefer SB. 


Discussion: This rule must be given high priority because it can 
affect interoperability. 


Rule 3: Avoid deprecated addresses. 

If one of the two source addresses is "preferred" and one of them is 
"deprecated" (in the RFC 4862 sense), then prefer the one that is 
"preferred". 


Rule 4: Prefer home addresses. 

If SA is simultaneously a home address and care-of address and SB is 
not, then prefer SA. Similarly, if SB is simultaneously a home 
address and care-of address and SA is not, then prefer SB. If SA is 
just a home address and SB is just a care-of address, then prefer SA. 
Similarly, if SB is just a home address and SA is just a care-of 
address, then prefer SB. 


Implementations supporting home addresses MUST provide a mechanism 
allowing an application to reverse the sense of this preference and 
prefer care-of addresses over home addresses (e.g., via appropriate 
API extensions such as [RFC5014]). Use of the mechanism MUST only 
affect the selection rules for the invoking application. 


Rule 5: Prefer outgoing interface. 

If SA is assigned to the interface that will be used to send to D and 
SB is assigned to a different interface, then prefer SA. Similarly, 
if SB is assigned to the interface that will be used to send to D and 
SA is assigned to a different interface, then prefer SB. 


Rule 5.5: Prefer addresses in a prefix advertised by the next-hop. 

If SA or SA's prefix is assigned by the selected next-hop that will 
be used to send to D and SB or SB’s prefix is assigned by a different 
next-hop, then prefer SA. Similarly, if SB or SB’s prefix is 
assigned by the next-hop that will be used to send to D and SA or 
SA's prefix is assigned by a different next-hop, then prefer SB. 
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Discussion: An IPv6 implementation is not required to remember 


which next-hops advertised which prefixes. The conceptual models 
of IPv6 hosts in Section 5 of [RFC4861] and Section 3 of [RFC4191] 
have no such requirement. Hence, Rule 5.5 is only applicable to 


implementations that track this information. 


Rule 6: Prefer matching label. 


If Label(SA) = Label(D) and Label(SB) <> Label(D), then prefer SA. 
Similarly, if Label(SB) = Label(D) and Label(SA) <> Label(D), then 
prefer SB. 


Rule 7: Prefer temporary addresses. 

If SA is a temporary address and SB is a public address, then prefer 
SA. Similarly, if SB is a temporary address and SA is a public 
address, then prefer SB. 


Implementations MUST provide a mechanism allowing an application to 
reverse the sense of this preference and prefer public addresses over 
temporary addresses (e.g., via appropriate API extensions such as 
[RFC5014]). Use of the mechanism MUST only affect the selection 
rules for the invoking application. This default is intended to 
address privacy concerns as discussed in [RFC4941] but introduces a 
risk of applications potentially failing due to the relatively short 
lifetime of temporary addresses or due to the possibility of the 
reverse lookup of a temporary address either failing or returning a 
randomized name. Implementations for which application compatibility 
considerations outweigh these privacy concerns MAY reverse the sense 
of this rule and by default prefer public addresses over temporary 
addresses. There SHOULD be an administrative option (the Privacy 
Preference flag) to change this preference, if the implementation 
supports temporary addresses. If there is no such option, there MUST 
be an administrative option to disable temporary addresses. 


Rule 8: Use longest matching prefix. 

If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then prefer SA. 
Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then 
prefer SB. 


Rule 8 MAY be superseded if the implementation has other means of 
choosing among source addresses. For example, if the implementation 
somehow knows which source address will result in the "best" 
communications performance. 
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Destination Address Selection 


The destination address selection algorithm takes a list of 
destination addresses and sorts the addresses to produce a new list. 
It is specified here in terms of the pair-wise comparison of 
addresses DA and DB, where DA appears before DB in the original list. 


The algorithm sorts together both IPv6 and IPv4 addresses. To find 
the attributes of an IPv4 address in the policy table, the IPv4 
address MUST be represented as an IPv4-mapped address. 


We write Source(D) to indicate the selected source address for a 
destination D. For IPv6 addresses, the previous section specifies 
the source address selection algorithm. Source address selection for 
IPv4 addresses is not specified in this document. 


We say that Source(D) is undefined if there is no source address 
available for destination D. For IPv6 addresses, this is only the 
case if CandidateSource(D) is the empty set. 


The pair-wise comparison of destination addresses consists of ten 
rules, which MUST be applied in order. If a rule determines a 
result, then the remaining rules are not relevant and MUST be 
ignored. Subsequent rules act as tiebreakers for earlier rules. See 
the previous section for a lengthier description of how pair-wise 
comparison tiebreaker rules can be used to sort a list. 


Rule 1: Avoid unusable destinations. 

If DB is known to be unreachable or if Source(DB) is undefined, then 
prefer DA. Similarly, if DA is known to be unreachable or if 

Source (DA) is undefined, then prefer DB. 


Discussion: An implementation might know that a particular 
destination is unreachable in several ways. For example, the 
destination might be reached through a network interface that is 
currently unplugged. For example, the implementation might retain 
information from Neighbor Unreachability Detection [RFC4861] for 


some period of time. In any case, the determination of 
unreachability for the purposes of this rule is implementation- 
dependent. 


Rule 2: Prefer matching scope. 


If Scope (DA) = Scope (Source (DA)) and Scope(DB) <> Scope (Source (DB)), 
then prefer DA. Similarly, if Scope(DA) <> Scope(Source(DA)) and 
Scope (DB) = Scope(Source(DB)), then prefer DB. 
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Rule 3: Avoid deprecated addresses. 

If Source(DA) is deprecated and Source(DB) is not, then prefer DB. 
Similarly, if Source(DA) is not deprecated and Source(DB) is 
deprecated, then prefer DA. 


Rule 4: Prefer home addresses. 

If Source(DA) is simultaneously a home address and care-of address 
and Source(DB) is not, then prefer DA. Similarly, if Source(DB) is 
simultaneously a home address and care-of address and Source(DA) is 
not, then prefer DB. 


If Source(DA) is just a home address and Source(DB) is just a care-of 
address, then prefer DA. Similarly, if Source(DA) is just a care-of 


address and Source(DB) is just a home address, then prefer DB. 


Rule 5: Prefer matching label. 


If Label (Source(DA)) = Label(DA) and Label (Source(DB)) <> Label(DB), 
then prefer DA. Similarly, if Label(Source(DA)) <> Label(DA) and 
Label (Source (DB)) = Label(DB), then prefer DB. 


Rule 6: Prefer higher precedence. 
If Precedence (DA) > Precedence (DB), then prefer DA. Similarly, if 
Precedence (DA) < Precedence (DB), then prefer DB. 


Rule 7: Prefer native transport. 

If DA is reached via an encapsulating transition mechanism (e.g., 
IPv6 in IPv4) and DB is not, then prefer DB. Similarly, if DB is 
reached via encapsulation and DA is not, then prefer DA. 


Discussion: The IPv6 Rapid Deployment on IPv4 Infrastructures 
(6rd) Protocol [RFC5969], the Intra-Site Automatic Tunnel 
Addressing Protocol (ISATAP) [RFC5214], and configured tunnels 
[RFC4213] are examples of encapsulating transition mechanisms for 
which the destination address does not have a specific prefix and 
hence can not be assigned a lower precedence in the policy table. 
An implementation MAY generalize this rule by using a concept of 
interface preference and giving virtual interfaces (like the IPv6- 
in-IPv4 encapsulating interfaces) a lower preference than native 
interfaces (like ethernet interfaces). 


Rule 8: Prefer smaller scope. 


If Scope(DA) < Scope(DB), then prefer DA. Similarly, if Scope(DA) > 
Scope (DB), then prefer DB. 
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Rule 9: Use longest matching prefix. 

When DA and DB belong to the same address family (both are IPv6 or 
both are IPv4): If CommonPrefixLen(Source(DA), DA) > 
CommonPrefixLen(Source(DB), DB), then prefer DA. Similarly, if 
CommonPrefixLen (Source (DA), DA) < CommonPrefixLen(Source(DB), DB), 
then prefer DB. 


Rule 10: Otherwise, leave the order unchanged. 
If DA preceded DB in the original list, prefer DA. Otherwise, prefer 
DB. 


Rules 9 and 10 MAY be superseded if the implementation has other 
means of sorting destination addresses. For example, if the 
implementation somehow knows which destination addresses will result 
in the "best" communications performance. 


7. Interactions with Routing 


This specification of source address selection assumes that routing 
(more precisely, selecting an outgoing interface on a node with 
multiple interfaces) is done before source address selection. 
However, implementations MAY use source address considerations as a 
tiebreaker when choosing among otherwise equivalent routes. 


For example, suppose a node has interfaces on two different links, 
with both links having a working default router. Both of the 
interfaces have preferred (in the RFC 4862 sense) global addresses. 
When sending to a global destination address, if there’s no routing 
reason to prefer one interface over the other, then an implementation 
MAY preferentially choose the outgoing interface that will allow it 
to use the source address that shares a longer common prefix with the 
destination. 


Implementations that support Rule 5.5 of source address selection 
(Section 5) also use the choice of router to influence the choice of 
source address. For example, suppose a host is on a link with two 
routers. One router is advertising a global prefix A and the other 
router is advertising global prefix B. Then, when sending via the 
first router, the host might prefer source addresses with prefix A 
and when sending via the second router, prefer source addresses with 
prefix B. 


8. Implementation Considerations 
The destination address selection algorithm needs information about 
potential source addresses. One possible implementation strategy is 


for getaddrinfo() to call down to the network layer with a list of 
destination addresses, sort the list in the network layer with full 
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current knowledge of available source addresses, and return the 
sorted list to getaddrinfo(). This is simple and gives the best 
results, but it introduces the overhead of another system call. One 
way to reduce this overhead is to cache the sorted address list in 
the resolver, so that subsequent calls for the same name do not need 
to re-sort the list. 


Another implementation strategy is to call down to the network layer 
to retrieve source address information and then sort the list of 
addresses directly in the context of getaddrinfo(). To reduce 
overhead in this approach, the source address information can be 
cached, amortizing the overhead of retrieving it across multiple 
calls to getaddrinfo(). In this approach, the implementation might 
not have knowledge of the outgoing interface for each destination, so 
it MAY use a looser definition of the candidate set during 
destination address ordering. 


In any case, if the implementation uses cached and possibly stale 
information in its implementation of destination address selection or 
if the ordering of a cached list of destination addresses is possibly 
stale, then it MUST ensure that the destination address ordering 
returned to the application is no more than one second out of date. 
For example, an implementation might make a system call to check if 
any routing table entries, source address assignments, or prefix 
policy table entries that might affect these algorithms have changed. 
Another strategy is to use an invalidation counter that is 
incremented whenever any underlying state is changed. By caching the 
current invalidation counter value with derived state and then later 
comparing against the current value, the implementation could detect 
if the derived state is potentially stale. 


9. Security Considerations 


This document has no direct impact on Internet infrastructure 
security. 


Note that most source address selection algorithms, including the one 
specified in this document, expose a potential privacy concern. An 
unfriendly node can infer correlations among a target node’s 
addresses by probing the target node with request packets that force 
the target host to choose its source address for the reply packets 
(perhaps because the request packets are sent to an anycast or 
multicast address or perhaps because the upper-layer protocol chosen 
for the attack does not specify a particular source address for its 
reply packets). By using different addresses for itself, the 
unfriendly node can cause the target node to expose the target’s own 
addresses. The source address selection default preference for 
temporary addresses helps mitigate this concern. 
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Similarly, most source and destination address selection algorithms, 
including the one specified in this document, influence the choice of 
network path taken (as do routing algorithms that are orthogonal to, 
but used together with, such algorithms) and hence whether data might 
be sent over a path or network that might be more or less trusted 
than other paths or networks. Administrators should consider the 
security impact of the rows they configure in the prefix policy 
table, just as they should consider the security impact of the 
interface metrics used in the routing algorithms. 


In addition, some address selection rules might be administratively 
configurable. Care must be taken to make sure that all 
administrative options are secured against illicit modification, or 
else an attacker could redirect and/or block traffic. 


Examples 


This section contains a number of examples, first showing default 
behavior and then demonstrating the utility of policy table 
configuration. These examples are provided for illustrative 
purposes; they are not to be construed as normative. 


.1. Default Source Address Selection 


The source address selection rules, in conjunction with the default 
policy table, produce the following behavior: 


Destination: 2001:db8:1::1 
Candidate Source Addresses: 2001:db8:3::1 or fe80::1 
Result: 2001:db8::1 (prefer appropriate scope) 


Destination: ff05::1 
Candidate Source Addresses: 2001:db8:3::1 or fe80::1 
Result: 2001:db8:3::1 (prefer appropriate scope) 


Destination: 2001:db8:1::1 

Candidate Source Addresses: 2001:db8:1::1 (deprecated) or 
2001:db8:2::1 

Result: 2001:db8:1::1 (prefer same address) 


Destination: fe80::1 
Candidate Source Addresses: fe80::2 (deprecated) or 2001:db8:1::1 
Result: fe80::2 (prefer appropriate scope) 


Destination: 2001:db8:1::1 
Candidate Source Addresses: 2001:db8:1::2 or 2001:db8:3::2 
Result: 2001:db8:1:::2 (longest matching prefix) 
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Destination: 2001:db8:1::1 

Candidate Source Addresses: 2001:db8:1::2 (care-of address) or 2001: 
db8:3::2 (home address) 

Result: 2001:db8:3::2 (prefer home address) 


Destination: 2002:c633:6401::1 

Candidate Source Addresses: 2002:c633:6401::d5e3:7953:13eb:22e8 
(temporary) or 2001:db8:1::2 

Result: 2002:c633:6401: :d5e3:7953:13eb:22e8 (prefer matching label) 


Destination: 2001:db8:1::d5e3:0:0:1 

Candidate Source Addresses: 2001:db8:1::2 (public) or 
2001:db8:1::d5e3:7953:13eb:22e8 (temporary) 

Result: 2001:db8:1::d5e3:7953:13eb:22e8 (prefer temporary address) 


-2. Default Destination Address Selection 


The destination address selection rules, in conjunction with the 
default policy table and the source address selection rules, produce 
the following behavior: 


Candidate Source Addresses: 2001:db8:1::2 or fe80::1 or 169.254.13.78 
Destination Address List: 2001:db8:1::1 or 198.51.100.121 

Result: 2001:db8:1::1 (sre 2001:db8:1::2) then 198.51.100.121 (src 
169.254.13.78) (prefer matching scope) 


Candidate Source Addresses: fe80::1 or 198.51.100.117 

Destination Address List: 2001:db8:1::1 or 198.51.100.121 

Result: 198.51.100.121 (sre 198.51.100.117) then 2001:db8:1::1 (sre 
fe80::1) (prefer matching scope) 


Candidate Source Addresses: 2001:db8:1::2 or fe80::1 or 10.1.2.4 
Destination Address List: 2001:db8:1::1 or 10.1.2.3 

Result: 2001:db8:1::1 (sre 2001:db8:1::2) then 10.1.2.3 (sre 
10.1.2.4) (prefer higher precedence) 


Candidate Source Addresses: 2001:db8:1::2 or fe80::2 

Destination Address List: 2001:db8:1::1 or fe80::1 

Result: fe80::1 (src fe80::2) then 2001:db8:1::1 (src 2001:db8:1::2) 
(prefer smaller scope) 


Candidate Source Addresses: 2001:db8:1::2 (care-of address) or 2001: 
db8:3::1 (home address) or fe80::2 (care-of address) 

Destination Address List: 2001:db8:1::1 or fe80::1 

Result: 2001:db8:1::1 (src 2001:db8:3::1) then fe80::1 (src fe80::2) 
(prefer home address) 
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Candidate Source Addresses: 2001:db8:1::2 or fe80::2 (deprecated) 
Destination Address List: 2001:db8:1::1 or fe80::1 

Result: 2001:db8:1::1 (src 2001:db8:1::2) then fe80::1 (src fe80::2) 
(avoid deprecated addresses) 


Candidate Source Addresses: 2001:db8:1::2 or 2001:db8:3f44::2 or 
fe80::2 

Destination Address List: 2001:db8:1::1 or 2001:db8:3ffe::1 

Result: 2001:db8:1::1 (sre 2001:db8:1::2) then 2001:db8:3ffe::1 (src 
2001:db8:3f44::2) (longest matching prefix) 


Candidate Source Addresses: 2002:c633:6401::2 or fe80::2 

Destination Address List: 2002:c633:6401::1 or 2001:db8:1::1 

Result: 2002:c633:6401::1 (sre 2002:c633:6401::2) then 2001:db8:1::1 
(src 2002:c633:6401::2) (prefer matching label) 


Candidate Source Addresses: 2002:c633:6401::2 or 2001:db8:1::2 or 
fe80::2 

Destination Address List: 2002:c633:6401::1 or 2001:db8:1::1 

Result: 2001:db8:1::1 (sre 2001:db8:1::2) then 2002:c633:6401::1 (sre 
2002:c633:6401::2) (prefer higher precedence) 


3. Configuring Preference for IPv6 or IPv4 


The default policy table gives IPv6 addresses higher precedence than 
IPv4 addresses. This means that applications will use IPv6 in 
preference to IPv4 when the two are equally suitable. An 
administrator can change the policy table to prefer IPv4 addresses by 
giving the ::ffff:0.0.0.0/96 prefix a higher precedence: 


Prefix Precedence Label 
::1/128 50 0 
::/0 40 1 
::ffff:0:0/96 100 4 
2002::/16 30 2 
2001::/32 5 5 
£c00::/7 3 13 
21/96 1 3 
fec0::/10 1 11 
3ffe::/16 il 12 


This change to the default policy table produces the following 
behavior: 


Candidate Source Addresses: 2001:db8::2 or fe80::1 or 169.254.13.78 
Destination Address List: 2001:db8::1 or 198.51.100.121 

Unchanged Result: 2001:db8::1 (src 2001:db8::2) then 198.51.100.121 
(src 169.254.13.78) (prefer matching scope) 
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Candidate Source Addresses: fe80::1 or 198.51.100.117 
Destination Address List: 2001:db8::1 or 198.51.100.121 
Unchanged Result: 198.51.100.121 (src 198.51.100.117) then 
2001:db8::1 (src fe80::1) (prefer matching scope) 


Candidate Source Addresses: 2001:db8::2 or fe80::1 or 10.1.2.4 
Destination Address List: 2001:db8::1 or 10.1.2.3 

New Result: 10.1.2.3 (sre 10.1.2.4) then 2001:db8::1 (src 
2001:db8::2) (prefer higher precedence) 


3.1. Handling Broken IPv6 


One problem in practice that has been recently observed occurs when a 
host has IPv4 connectivity to the Internet but has "broken" IPv6 
connectivity to the Internet in that it has a global IPv6 address but 
is disconnected from the IPv6 Internet. Since the default policy 
table prefers IPv6, this can result in unwanted timeouts. 


This can be solved by configuring the table to prefer IPv4 as shown 
above. An implementation that has some means to detect that it is 
not connected to the IPv6 Internet MAY do this automatically. An 
implementation could instead treat it as part of its implementation 
of Rule 1 (avoid unusable destinations). 


4. Configuring Preference for Link-Local Addresses 


The destination address selection rules give preference to 
destinations of smaller scope. For example, a link-local destination 
will be sorted before a global scope destination when the two are 
otherwise equally suitable. An administrator can change the policy 
table to reverse this preference and sort global destinations before 
link-local destinations: 


Prefix Precedence Label 
::1/128 50 0 
Hey Ale) 40 1 
::ffff£:0:0/96 35 4 
fe80::/10 33 1 
2002::/16 30 2 
2001::/32 5 5 
£c00::/7 3 13 
22/96 1 3 
fec0::/10 1 11 
3ffe::/16 1 12 
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This change to the default policy table produces the following 
behavior: 


Candidate Source Addresses: 2001:db8::2 or fe80::2 

Destination Address List: 2001:db8::1 or fe80::1 

New Result: 2001:db8::1 (sre 2001:db8::2) then fe80::1 (sre fe80::2) 
(prefer higher precedence) 


Candidate Source Addresses: 2001:db8::2 (deprecated) or fe80::2 
Destination Address List: 2001:db8::1 or fe80::1 

Unchanged Result: fe80::1 (src fe80::2) then 2001:db8::1 (src 2001: 
db8::2) (avoid deprecated addresses) 


5. Configuring a Multi-Homed Site 


Consider a site A that has a business-critical relationship with 
another site B. To support their business needs, the two sites have 
contracted for service with a special high-performance ISP. This is 
in addition to the normal Internet connection that both sites have 
with different ISPs. The high-performance ISP is expensive, and the 
two sites wish to use it only for their business-critical traffic 
with each other. 


Each site has two global prefixes, one from the high-performance ISP 
and one from their normal ISP. Site A has prefix 2001:db8:laaa::/48 
from the high-performance ISP and prefix 2001:db8:70aa::/48 from its 
normal ISP. Site B has prefix 2001:db8:1bbb::/48 from the high- 
performance ISP and prefix 2001:db8:70bb::/48 from its normal ISP. 
All hosts in both sites register two addresses in the DNS. 


The routing within both sites directs most traffic to the egress to 
the normal ISP, but the routing directs traffic sent to the other 
site’s 2001 prefix to the egress to the high-performance ISP. To 
prevent unintended use of their high-performance ISP connection, the 
two sites implement ingress filtering to discard traffic entering 
from the high-performance ISP that is not from the other site. 


The default policy table and address selection rules produce the 
following behavior: 


Candidate Source Addresses: 2001:db8:laaa::a or 2001:db8:70aa::a or 
fe80::a 

Destination Address List: 2001:db8:1bbb::b or 2001:db8:70bb::b 
Result: 2001:db8:70bb::b (src 2001:db8:70aa::a) then 2001:db8:1lbbb::b 
(src 2001:db8:laaa::a) (longest matching prefix) 
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In other words, when a host in site A initiates a connection to a 
host in site B, the traffic does not take advantage of their 
connections to the high-performance ISP. This is not their desired 
behavior. 


Candidate Source Addresses: 2001:db8:laaa::a or 2001:db8:70aa::a or 
fe80::a 

Destination Address List: 2001:db8:lccc::c or 2001:db8:6ccc::c 
Result: 2001:db8:lccc::c (src 2001:db8:laaa::a) then 2001:db8:6ccc::c 
(src 2001:db8:70aa::a) (longest matching prefix) 


In other words, when a host in site A initiates a connection to a 
host in some other site C, the reverse traffic might come back 
through the high-performance ISP. Again, this is not their desired 
behavior. 


This predicament demonstrates the limitations of the longest- 
matching-prefix heuristic in multi-homed situations. 


However, the administrators of sites A and B can achieve their 
desired behavior via policy table configuration. For example, they 
can use the following policy table: 


Prefix Precedence Label 
::1/128 50 0 
2001:db8:laaa::/48 43 6 
2001:db8:1bbb::/48 43 6 
2:/0 40 1 
::ffff£:0:0/96 35 4 
2002::/16 30 2 
2001::/32 5 5 
£c00::/7 3 13 
::/96 1 3 
fec0::/10 1 11 
3ffe::/16 1 12 


This policy table produces the following behavior: 


Candidate Source Addresses: 2001:db8:laaa::a or 2001:db8:70aa::a or 
fe80::a 

Destination Address List: 2001:db8:1lbbb::b or 2001:db8:70bb::b 

New Result: 2001:db8:1bbb::b (src 2001:db8:laaa::a) then 2001:db8: 
70bb::b (src 2001:db8:70aa::a) (prefer higher precedence) 


In other words, when a host in site A initiates a connection to a 
host in site B, the traffic uses the high-performance ISP as desired. 
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Candidate Source Addresses: 2001:db8:laaa::a or 2001:db8:70aa::a or 
fe80::a 

Destination Address List: 2001:db8:lccc::c or 2001:db8:6ccc::c 

New Result: 2001:db8:6ccc::c (sre 2001:db8:70aa::a) then 2001:db8: 
lcce::c (src 2001:db8:70aa::a) (longest matching prefix) 


In other words, when a host in site A initiates a connection to a 
host in some other site C, the traffic uses the normal ISP as 
desired. 


6. Configuring ULA Preference 


Sections 2.1.4, 2.2.2, and 2.2.3 of RFC 5220 [RFC5220] describe 
address selection problems related to Unique Local Addresses (ULAs) 
[RFC4193]. By default, global IPv6 destinations are preferred over 
ULA destinations, since an arbitrary ULA is not necessarily 
reachable: 


Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1 
Destination Address List: 2001:db8:2::2 or £d22:2222:2222:2::2 
Result: 2001:db8:2::2 (src 2001:db8:1::1) then £d22:2222:2222:2::2 
(src fd11:1111:1111:1::1) (prefer higher precedence) 


However, a site-specific policy entry can be used to cause ULAs 
within a site to be preferred over global addresses as follows. 


Prefix Precedence Label 
2217128 50 0 
£d11:1111:1111::/48 45 14 
::/0 40 1 
::ffff:0:0/96 35 4 
2002::/16 30 2 
2001::/32 5 5 
£c00::/7 3 13 
21/96 1 3 
fec0::/10 1 11 
3ffe::/16 1 12 


Such a configuration would have the following effect: 


Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1 
Destination Address List: 2001:db8:2::2 or £d22:2222:2222:2::2 
Unchanged Result: 2001:db8:2::2 (src 2001:db8:1::1) then £d22:2222: 
2222:2::2 (src fd11:1111:1111:1::1) (prefer higher precedence) 
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Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1 
Destination Address List: 2001:db8:2::2 or fd11:1111:1111:2::2 

New Result: fd11:1111:1111:2::2 (sre fd11:1111:1111:1::1) then 2001: 
db8:2::2 (src 2001:db8:1::1) (prefer higher precedence) 


Since ULAs are defined to have a /48 site prefix, an implementation 
might choose to add such a row automatically on a machine with a ULA. 


It is also worth noting that ULAs are assigned global scope. As 
such, the existence of one or more rows in the prefix policy table is 
important so that source address selection does not choose a ULA 
purely based on longest match: 


Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1 
Destination Address List: ff00:1 
Result: 2001:db8:1::1 (prefer matching label) 


7. Configuring 6to4 Preference 
By default, NATed IPv4 is preferred over 6to4-relayed connectivity: 


Candidate Source Addresses: 2002:c633:6401::2 or 10.1.2.3 
Destination Address List: 2001:db8:1::1 or 203.0.113.1 

Result: 203.0.113.1 (sre 10.1.2.3) then 2001:db8:1::1 (src 2002:c633: 
6401::2) (prefer matching label) 


However, NATed IPv4 is now also preferred over 6to4-to-6to4 
connectivity by default. Since a 6to4 prefix might be used natively 
within an organization, a site-specific policy entry can be used to 
cause native IPv6é communication (using a 6to4 prefix) to be preferred 
over NATed IPv4 as follows. 


Prefix Precedence Label 
::1/128 50 0 
2002:c633:6401::/48 45 14 
3/0 40 al 
::ffff:0:0/96 35 4 
2002::/16 30 2 
2001::/32 5 5 
£c00::/7 3 13 
21/96 1 3 
fec0::/10 1 11 
3ffe::/16 1 12 
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Such a configuration would have the following effect: 


Candidate Source Addresses: 2002:c633:6401:1::1 or 10.1.2.3 
Destination Address List: 2002:c633:6401:2::2 or 203.0.113.1 
New Result: 2002:c633:6401:2::2 (src 2002:c633:6401:1::1) then 
203.0.113.1 (sec 10.1.2.3) (prefer higher precedence) 


Since 6to4 addresses are defined to have a /48 site prefix, an 
implementation might choose to add such a row automatically ona 
machine with a native IPv6 address with a 6to4 prefix. 
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Appendix B. Changes since RFC 3484 


Some changes were made to the default policy table that were deemed 
to be universally useful and cause no harm in every reasonable 
network environment. In doing so, care was taken to use the same 
preference and label values as in RFC 3484 whenever possible and for 
new rows to use label values less likely to collide with values that 
might already be in use in additional rows on some hosts. These 
changes are: 


1. Added the Teredo [RFC4380] prefix (2001::/32), with the 
preference and label values already widely used in popular 
implementations. 


2. Added a row for ULAs (fc00::/7) below native IPv6 since they are 
not globally reachable, as discussed in Section 10.6. 


3. Added a row for site-local addresses (fec0::/10) in order to 
depreference them, for consistency with the example in 
Section 10.3, since they are deprecated [RFC3879]. 


4. Depreferenced 6to4 (2002::/32) below native IPv4 since 6to4 
connectivity is less reliable today (and is expected to be phased 
out over time, rather than becoming more reliable). It remains 
above Teredo since 6to4 is more efficient in terms of connection 
establishment time, bandwidth, and server load. 


5. Depreferenced IPv4-Compatible addresses (::/96) since they are 
now deprecated [RFC4291] and not in common use. 
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Added a row for 6bone testing addresses (3ffe::/16) in order to 
depreference them as they have also been phased out [RFC3701]. 


Added optional ability for an implementation to add automatic 
rows to the table for site-specific ULA prefixes and site- 
specific native 6to4 prefixes. 


Similarly, some changes were made to the rules, as follows: 


1. 


Thaler, 


Changed the definition of CommonPrefixLen() to only compare bits 
up to the source address’s prefix length. The previous 
definition used the entire source address, rather than only its 
prefix. As a result, when a source and destination addresses had 
the same prefix, common bits in the interface ID would previously 
result in overriding DNS load balancing [RFC1794] by forcing the 
destination address with the most bits in common to be always 
chosen. The updated definition allows DNS load balancing to 
continue to be used as a tie breaker. 


Added Rule 5.5 to allow choosing a source address from a prefix 
advertised by the chosen next-hop for a given destination. This 
allows better connectivity in the presence of BCP 38 [RFC2827] 
ingress filtering and egress filtering. Previously, RFC 3484 had 
issues with multiple egress networks reached via the same 
interface, as discussed in [RFC5220]. 


Removed restriction against anycast addresses in the candidate 
set of source addresses, since the restriction against using IPv6 
anycast addresses as source addresses was removed in Section 2.6 
of RFC 4291 [RFC4291]. 


Changed mapping of RFC 1918 [RFC1918] addresses to global scope 
in Section 3.2. Previously, they were mapped to site-local 
scope. However, experience has resulted in current 
implementations already using global scope instead. When they 
were mapped to site-local, Destination Address Selection Rule 2 
(Prefer matching scope) would cause IPv6 to be preferred in 
scenarios such as that described in Section 10.7. The change to 
global scope allows configurability via the prefix policy table. 


Changed the default recommendation for Source Address Selection 
Rule 7 to prefer temporary addresses rather than public 
addresses, while providing an administrative override (in 
addition to the application-specific override that was already 
specified). This change was made because of the increasing 
importance of privacy considerations, as well as the fact that 
widely deployed implementations have preferred temporary 
addresses for many years without major application issues. 
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Finally, some editorial changes were made, including: 


1; 


Thaler, 


Changed global IP addresses in examples to use ranges reserved 
for documentation. 


Added additional examples in Sections 10.6 and 10.7. 
Added Section 10.3.1 on "broken" IPv6. 


Updated references. 
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